home *** CD-ROM | disk | FTP | other *** search
- Path: Hermes.grace.irl.cri.nz!maths!peterm
- From: peterm@maths.grace.cri.nz (Peter McGavin)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Demos on graphiccards
- Date: 31 Jan 1996 10:18:28 GMT
- Organization: Industrial Research Ltd
- Distribution: world
- Message-ID: <PETERM.96Jan31231828@tui.maths.irl.cri.nz>
- References: <xB53AMD0asz2@wizzcat.prima.ruhr.de>
- <4eavqk$da8@sunsystem5.informatik.tu-muenchen.de>
- NNTP-Posting-Host: tui.grace.cri.nz
- In-reply-to: fischerj@informatik.tu-muenchen.de's message of 26 Jan 1996
- 16:34:28 GMT
-
- fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
- >well, supporting gfx-cards doesn't mean you need to fallback to
- >OS-routines for rendering. OS-rendering as option could speed up
- >on special hardware though.
-
- IMHO, it's the other way around. A demo must fall-back to high-level
- OS calls if it wants to support _all_ gfx-cards (including unknown and
- future cards). If a demo detects a known, particular card or custom
- chipset, then it could possibly go faster with an option to go right
- to the hardware.
-
- >|> See Gloom running systemfriendly !!
- >
- >Yes, that's nice. But it's too slow. Not because of sysfriendly, but
- >bacause of suboptimal c2p and suboptimal mapping.
-
- Feel free to write faster c2p routines than the ones I uploaded to
- Aminet game/demo/GloomC2P10.lha. Unfortunately the Gloom Deluxe Demo
- c2p interface doesn't seem to support async blitter, which would be
- faster on an '020. For CPU-only c2p, I think my routines would be
- hard to improve significantly (but I've been proved wrong before).
- --
- Peter McGavin. (p.mcgavin@irl.cri.nz)
-